home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
njm
/
njm-minutes-91mar.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
10KB
|
253 lines
CURRENT_MEETING_REPORT_
Reported by Robert J. Reschly, Jr./BRL
NJM Minutes
Agenda
Old Business
o Unexpected routing.
- Reports
- Operational Impact
- Action
* Is there anything which should be done?
* Is there anything which can be done?
o Other old issues - Communities?
New business
o Dale Johnson on trouble tickets.
Roundtable on current and expected issues
o Effects of development of Internet
- Scaling
- Speed
- ``low budget'' connections, users?
- International network coordination and mgt., etc.
After a brief review of the function of the NJM, there was another call
for ``unexpected routing'' anecdotes. The University of Delaware to
DuPont Delaware via Ithaca, NY and Reston, VA, and WestNET's 16 hops
across town routes were cited as examples. Also cited was the TWB
routing problem due to that router being connected directly to the
campus.
1
Others mentioned examples which were found to be a result of MILNET
problems, and one situation involving Argonne. All were understood and
have been or are being corrected.
The subject of diagnosing routing problems came up. Traceroute,
especially third-party traceroute where available, still seems to be the
most heavily used tool.
Tony Hain of ESNET informed those present of the community name for
ESNET's routers. This is strictly for use by other midlevel network
operators in the performance of their tasks. Others with a requirement
to access these routers should contact Tony. NSI is considering making
it's community name available as well.
Dale Johnson briefly outlined this week's discussions concerning NOC
trouble ticket systems. He has a draft (draft-ietf-ucp-tt-00.txt),
inspired by the UCP WG document (draft-ietf-ucp-connectivity-00.txt).
He feels that their focus on accountability to end user problem reports
and single NOC operations is not totally suitable for his purposes.
Dale is more concerned with inter-NOC network oriented operations.
Worth noting is that the TT discussions revealed a desire to make this
more universally useful -- i.e., by central site staff as well as NOC
staff. Dale will be publishing an updated document in a few weeks.
When questioned about whether any systems were going to be proposed, he
responded affirmatively. As a point of information, Gene Hastings
stated he felt the real goal of the the UCP paper was the establishment
of an inter-NOC transaction processing system for handling the passing
of problem reports between NOCs.
MERIT currently runs an IBM mainframe product, but is moving towards a
UNIX based TT system they may develop locally. IBM Yorktown is working
on xgmon; Tim Salo at MSC is funded to work on a UNIX implementation;
and Sun Microsystems is working on one as well... Word on developments
will be sent to the Trouble Ticket Requirements mailing list
<noc-tt-req@merit.edu> (-request for administrivia) as it becomes
available.
There was quite a bit of talk about the pros and cons of basing a TT
system on top of a DBMS. It is very easy to expend man-years of effort
in the design and integration of a DB based system -- time many
organizations simply do not have. A suggestion that we encourage some
company to produce and support a TT system was generally well received.
It was also observed that in many cases, the integration of a TT system
was going to involve some DB customization/interface work in any event.
A poll was taken about current TT operations. 10 sites have some sort
of online TT system (4 were ASCII --['sensibly' printable]); 5 were
paper systems; and three people reported having no formal TT system in
use. Someone noted there were two publicly available systems (are these
2
in NOCTOOLS?).
Conversation then moved on to the desirabilty of having links to other
portions of any existing DB -- examples involved things like
specification of a router filling in configuration information, and
mentioning a pair of routers completing link and telco contact
information. Again it was noted that this was a bigger win when the
``external'' components already existed. It was observed that there
must be products available which solve similar problems in areas like
inventory control, but that they were not necessarily TT oriented.
Unfortunately nobody could cite specific systems.
There was a call to formalize an operations track within the IETF.
Having this track would reduce internal schedule conflicts, and should
attempt to minimize conflicts with User Services as the two have
significant overlap.
The group then dove into an extended discussion of the undesirability of
referring all problems up towards MERIT. Members very much wanted the
ability to contact relevant parties in other regionals directly, but
expressed frustration at lack of contact information. Many rely on one
or more of the Internet Managers Phonebook, WHOIS, or stabs into the
DNS, but these often are only approximate reflections of reality. One
proposal was the addition of text/hinfo records incorporating contact
phone numbers.
Doug Gale <dgale@nsf.gov> is working on an NSF RFP for global user
services.. [something about a help server at MERIT -- call
(800)66-MERIT and ask about the help server].
There was a suggestion to add DNS records for networks as well as hosts
(e.g., lookup on 128.63.0.0 -- forward and inverse), along with a
warning that any records should match networks.txt.
Milo Medin had some comments concerning the new DDN NIC contract. The
new contract does not provide for network number assignment or DNS
registration among other things. [Later, Steve Wolff told us that DCA
and NSF are working together to ensure the continuity of essential
services.] More information will be sent to the mailing list as it
becomes available.
Kannan Varadhan then touched on his ongoing Telebit NetBlazer testing.
He has developed a list of things he wants to discuss with Telebit, and
solicits questions from others. The NJM mailing list <njm@merit.edu>
(-request for administrivia) will host the dialog with Kannan as his
testing continues (i.e., post your questions and answers to this list).
3
The basic NetBlazer is a 386 box running KA9Q, with 2 modem ports for a
total cost of ~$3,000.00. Additional ports are added in 8 port
increments. It offers packet driven dialup, and three authentication
methods: username/password; callback; and, between boxes, a crypto
handshake. NetBlazer does not do TACACS.
The TACACS comment prompted a number of requests for some sort of
authentication servers which may (at least optionally) be Internet-wide
in scope. Dale Johnson mentioned in passing that MERIT had just
deployed one for MICHNET.
Milo then talked briefly about NSI's plan for having a single 800 number
for his folks on travel. When called, this number would route to a hunt
group of lines local to that area. He also mentioned that it was still
possible to assign fixed IP addresses with this and still have routing
work (under OSPF if it was a single area -- OSPF used best match.).
After the discussion was wrenched back to the agenda, it was asserted
that overall European routing is a disaster, even if internal (i.e.,
ESNET or NSI European routing appeared to be sensible). Dave O'leary
noted that in many cases routing was set based on technical
considerations even when they conflicted with policy considerations.
SURA continues to take heat on this issue. It was felt that the
FEPG/FRICC work would help. The FEPG has developed guidelines which
formalize connectivity in accordance with CCIRN recommendations.
At this point Milo insisted that NOCs contemplating international
operation absolutely positively must have 24 x 7 NOC operations.
We were told that SPRINT and Cornell (the NSF International connection
managers) want to schedule a global BGP, coordination and cutover
meeting. The current best guess has this meeting taking place at the
July IETF in Atlanta.
Someone wondered if the decisions were unilateral or bilateral. The
IEPG is a technically oriented group doing sensible things, but it is
not clear the IEPG is in a position to significantly affect the decision
process. Their next meeting is in Paris in early May. It was also
noted that many of the problems appeared to be intra-European.
We then moved on to a very brief consideration of what connecting hordes
of high schools would entail. A quick survey showed three regionals are
planning to connect 10 or more high schools in the coming year, and in
at least one case, these connections will connect whole districts.
The humor quotient chose that time to take a significant nosedive so we
adjourned.
4
Attendees
Vikas Aggarwal vikas@JVNC.net
Jordan Becker becker@nis.ans.net
Tom Easterday tom@cic.net
Dale Finkelson dmf@westie.unl.edu
Vince Fuller vaf@Standford.EDU
Shari Galitzer shari@gateway.mitre.org
Joseph Golio golio@cray.com
Eugene Hastings hastings@psc.edu
Steven Hunter hunter@es.net
Dale Johnson dsj@merit.edu
Dan Jordt danj@nwnet.net
Daniel Long long@nic.near.net
Milo Medin medin@nsipo.nasa.gov
Bill Norton wbn@merit.edu
David O'Leary oleary@sura.net
Robert Reschly reschly@brl.mil
Ron Roberts roberts@jessica.stanford.edu
Roxanne Streeter streeter@nsipo.nasa.gov
Kannan Varadhan kannan@oar.net
Ross Veach rrv@uiuc.edu
Carol Ward cward@spot.colorado.edu
C. Philip Wood cpw@lanl.gov
5